Skunkware 5

home *** CD-ROM | disk | FTP | other *** search

/ Skunkware 5 / Skunkware 5.iso / man / cat.8 / lsof.8 < prev next >

Wrap

Text File | 1995-07-31 | 78.4 KB | 1,651 lines

LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) NNNNAAAAMMMMEEEE lsof - list open files SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS llllssssooooffff [ ----????aaaabbbbCCCChhhhHHHHllllnnnnNNNNooooOOOOPPPPssssttttUUUUwwwwXXXX ] [ ----cccc _c ] [ ----dddd _d ] [ ----DDDD _D ] [ ----FFFF [_f] ] [ ----gggg [_s] ] [ ----iiii _i ] [ ----kkkk _k ] [ ----mmmm _m ] [ ----pppp _s ] [ ----rrrr [_t] ] [ ----SSSS [_t] ] [ ----uuuu _s ] [ -------- ] _n_a_m_e_s DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _L_s_o_f revision 3.37 lists information about files opened by processes for the following Unix dialects: AIX 3.2.4, 3.2.5, 4.1, 4.1.1, and 4.1.2 for the IBM RISC/System 6000 DC/OSx 1.1 for Pyramid ES, Nile, and S series DYNIX 3.0.12 (Purdue version) for the Sequent Symmetry EP/IX 2.1.1 for the CDC 4680 FreeBSD 1.1.5.1, 2.0, and 2.0.5 for Intel-based systems HP-UX 8.x, 9.x, and 10 for HP systems IRIX 4.0.5H, 5.2, 5.3, and 6.0 for SGI systems Linux through 1.2.11 for Intel-based systems Motorola V/88 for R32V3, R40V4.2, and R40V4.3 M88K systems NetBSD 1.0 and 1.0A for Intel and SPARC-based systems NEXTSTEP 2.1 and 3.[0123], all architectures Novell UnixWare 1.1, 1.1.1, and 1.1.2 for Intel-based systems OSF/1 1.3, 2.0, 3.0, and 3.2 for DEC Alpha PTX 2.1.[156] and 4.0.[23] for Sequent systems RISC/os 4.52 for MIPS R2000-based systems SCO OpenDesktop or OpenServer 1.1, 3.0, and 5.0 for Intel-based systems Solaris 2.[1234] SunOS 4.1.[1234] Ultrix 2.2, 4.2, 4.3, and 4.4 for DEC RISC and VAX An open file may be a regular file, a directory, a block special file, a character special file, an executing text reference, a library, a stream or a network file (Internet socket, NFS file or Unix domain socket.) A specific file or all the files in a file system may be selected by path. Instead of a formatted display, _l_s_o_f will produce output that can be parsed by other programs. See the ----FFFF, option description, and the OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRR OOOOTTTTHHHHEEEERRRR PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS section for more information. In addition to producing a single output list, _l_s_o_f will run in repeat mode. In repeat mode it will produce output, delay, then repeat the output operation until stopped with an interrupt or quit signal. See the ----rrrr [_t] option description for more information. Page 1 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) _L_s_o_f may work on other Unix dialects - e.g., AIX 3.2.3, EP/IX 1.4.3, FreeBSD 1.0e, HP-UX 7.x, IRIX 5.1.1, NEXTSTEP 2.[01], and SunOS 4.1 - but has not been tested on any of them recently. OOOOPPPPTTTTIIIIOOOONNNNSSSS In the absence of any options, _l_s_o_f lists all open files belonging to all active processes. If any list request option is specified, other list requests must be specifically requested - e.g., if ----nnnn is specified for the listing of Internet and x.25 (HP-UX) network files, NFS files won't be listed unless ----NNNN is also specified; or if a user list is specified with the ----uuuu option, Internet and x.25 (HP-UX) network files and Unix domain socket files, belonging to users not in the list, won't be listed unless the ----nnnn and ----UUUU options are also specified. Normally list options that are specifically stated are ORed - i.e., specifying the ----nnnn and ----uuuufoo options produces a listing of all network files OR files belonging to processes owned by user ``foo''. The ----aaaa option may be used to AND the selections. For example, specifying ----aaaa, ----nnnn, and ----uuuufoo produces a listing of only network files that belong to processes owned by user ``foo''. Caution: the ----aaaa option causes all list selection options to be ANDed; it can't be used to cause ANDing of selected pairs of selection options by placing it between them, even though its placement there is acceptable. Wherever ----aaaa is placed, it causes the ANDing of all selection options. Items of the same selection set - command names, file descriptors, network addresses, process identifiers, user identifiers - are joined in a single ORed set and applied before the result participates in ANDing. Thus, for example, specifying ----iiii@aaa.bbb, ----iiii@ccc.ddd, ----aaaa, and ----uuuufff,ggg will select the listing of files that belong to either login ``fff'' OR ``ggg'' AND have network connections to either host aaa.bbb OR ccc.ddd. Values are optional following several options: ----FFFF, ----gggg, ----rrrr, and ----SSSS. When you have no values for these options, be careful that the following character isn't ambiguous. For example, ----FFFFnnnn might represent the ----FFFF and ----nnnn options, or it might represent the nnnn field identifier character following the ----FFFF option. When ambiguity is possible, start a new option with a `-' character - e.g., ``----FFFF ----nnnn''. If the next option is a file name, follow the possibly ambiguous option with ``--'' - e.g., ``----FFFF -------- _n_a_m_e''. ----???? ----hhhh These two options select a usage (help) output Page 2 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) list. _L_s_o_f displays a shortened form of this output when it detects an error in the options supplied to it, after it has displayed messages explaining each error. ----aaaa This option causes list selection options to be ANDed, as described above. ----bbbb This option causes _l_s_o_f to avoid kernel functions that might block - _l_s_t_a_t(2), _r_e_a_d_l_i_n_k(2), and _s_t_a_t(2). See the BBBBLLLLOOOOCCCCKKKKSSSS AAAANNNNDDDD TTTTIIIIMMMMEEEEOOOOUUUUTTTTSSSS and AAAAVVVVOOOOIIIIDDDDIIIINNNNGGGG KKKKEEEERRRRNNNNEEEELLLL BBBBLLLLOOOOCCCCKKKKSSSS sections for information on using this option. ----cccc _c This option selects the listing of files for processes executing the command named _c. Multiple commands may be specified, using multiple ----cccc options. They are joined in a single ORed set before participating in AND option selection. Caution: since _l_s_o_f truncates command names to nine characters, when you specify a name longer than that with ----cccc, _l_s_o_f won't find it. ----CCCC This option disables the reporting of partial path name components from the kernel's name cache. See the KKKKEEEERRRRNNNNEEEELLLL NNNNAAAAMMMMEEEE CCCCAAAACCCCHHHHEEEE section for more information. ----dddd _d This option selects the listing of files whose file descriptor number or name is _d. Multiple file descriptors my be specified, using multiple ----dddd options. They are joined in a single ORed set before participating in AND option selection. See the description of File Descriptor (FD) output values in the OOOOUUUUTTTTPPPPUUUUTTTT section for more information on file descriptor names. ----DDDD _D This option directs _l_s_o_f'_s use of the device cache file. (See the DDDDEEEEVVVVIIIICCCCEEEE CCCCAAAACCCCHHHHEEEE FFFFIIIILLLLEEEE for more information on it.) ----DDDD must be followed by a function letter; the function letter may optionally be followed by a path name. _L_s_o_f recognizes these function letters: bbbb - build the device cache iiii - ignore the device cache rrrr - read the device cache uuuu - read and update the device cache Page 3 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) The iiii, rrrr, and uuuu functions may be followed by the device cache file's path. The standard default is /_t_m_p/._l_s_o_f__d_e_v__c_a_c_h_e, but this could have been changed when _l_s_o_f was configured and compiled. (The output of the ----???? and ----hhhh options show the current default.) The bbbb function directs _l_s_o_f to build a new device cache file at the default or specified path. The iiii function directs _l_s_o_f to ignore the default device cache file and obtain its information about devices via direct calls to the kernel. The rrrr function directs _l_s_o_f to read the device cache at the default or specified path, but prevents it from creating a new device cache file when none exists or the existing one is improperly structured. The uuuu function directs _l_s_o_f to read the device cache file at the default or specified path, if possible, and to rebuild it, if necessary. This is the default device cache file function when no ----DDDD option has been specified. ----FFFF _f This option specifies a character list, _f, that selects the fields to be output for processing by another program, and the character that terminates each output field. Each field to be output is specified with a single character in _f. The field terminator defaults to NL, but may be changed to NUL (000). See the OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRR OOOOTTTTHHHHEEEERRRR PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS section for a description of the field identification characters and the field output process. When the field selection character list is empty, all fields are selected and the NL field terminator is used. When the field selection character list contains only a zero (`0'), all fields are selected and the NUL terminator character is used. Other combinations of fields and their associated field terminator character must be set with explicit entries in _f, as described in the OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRR OOOOTTTTHHHHEEEERRRR PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS section. When the field selection character list contains the single character `?', _l_s_o_f will display a help Page 4 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) list of the field identification characters. (Escape the `?' character as your shell requires.) ----gggg [_s] This option selects the listing of files for the processes whose optional process group IDentification (PGRP) numbers are in the comma-separated set _s - e.g., ``123'' or ``123,456''. (There should be no spaces in the set.) Multiple PGRP numbers are joined in a single ORed set before participating in AND option selection. The ----gggg option also enables the output display of PGRP numbers. When specified without a PGRP set that's all it does. ----HHHH This option inhibits the conversion of network numbers to host names for network files. Inhibiting conversion may make _l_s_o_f run a little faster. It is also useful when host name lookup is not working properly. ----iiii _i This option selects the listing of files any of whose Internet address matches the address specified in _i. Multiple addresses may be specified with multiple ----iiii options. They are joined in a single ORed set before participating in AND option selection. An Internet address is specified in the form: [_p_r_o_t_o_c_o_l][@_h_o_s_t_n_a_m_e|_h_o_s_t_a_d_d_r][:_s_e_r_v_i_c_e|_p_o_r_t] where: _p_r_o_t_o_c_o_l is a protocol name - e.g., TTTTCCCCPPPP. _h_o_s_t_n_a_m_e is an Internet host name. _h_o_s_t_a_d_d_r is an Internet host address in dot form. _s_e_r_v_i_c_e is an /_e_t_c/_s_e_r_v_i_c_e_s name - e.g., ssssmmmmttttpppp. _p_o_r_t is a port number. At least one address component - _p_r_o_t_o_c_o_l, host specification, or port specification - must be supplied. The `@' character, leading the host specification, is always required; as is the `:', leading the port specification. Specify either _h_o_s_t_n_a_m_e or _h_o_s_t_a_d_d_r. Specify either _s_e_r_v_i_c_e name or _p_o_r_t number. If _s_e_r_v_i_c_e is specified, _p_r_o_t_o_c_o_l must also be specified. Use any case - lower or upper - for _p_r_o_t_o_c_o_l. Here are some sample addresses: Page 5 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) TCP:25 - TCP and port 25 @1.2.3.4 - Internet host address 1.2.3.4 UDP:who - UDP who service port TCP@vic.cc:513 - TCP, port 513 and host name vic.cc ----kkkk _k This option specifies a kernel name list file, _k, in place of /vmunix, /mach, /dynix, etc. This option is not available under AIX on the IBM RISC/System 6000. ----llll This option inhibits the conversion of user ID numbers to login names. It is also useful when login name lookup is working improperly or slowly. ----mmmm _m This option specifies a kernel memory file, _c, in place of /dev/kmem or /dev/mem - e.g., a crash dump file. ----nnnn This option selects the listing of Internet and x.25 (HP-UX) network files. ----NNNN This option selects the listing of NFS files. ----oooo This option directs _l_s_o_f to display file offset at all times. It causes the SIZE/OFF output column title to be changed to OFFSET. The ----oooo and ----ssss options are mutually exclusive; they can't both be specified. When neither is specified, _l_s_o_f displays whatever value - size or offset - is appropriate for the type of the file. ----OOOO This option directs _l_s_o_f to bypass the strategy it uses to avoid being blocked by some kernel operations - i.e., doing them in forked child processes. See the BBBBLLLLOOOOCCCCKKKKSSSS AAAANNNNDDDD TTTTIIIIMMMMEEEEOOOOUUUUTTTTSSSS and AAAAVVVVOOOOIIIIDDDDIIIINNNNGGGG KKKKEEEERRRRNNNNEEEELLLL BBBBLLLLOOOOCCCCKKKKSSSS for more information on kernel operations that may block _l_s_o_f. While use of this option will reduce _l_s_o_f startup overhead, it may also cause _l_s_o_f to hang when the kernel doesn't respond to a function. Use this option cautiously. ----pppp _s This option selects the listing of files for the processes whose ID numbers are in the comma-separated set _s - e.g., ``123'' or ``123,456''. (There should be no spaces in the set.) Multiple process ID numbers are joined in a single ORed set before participating in AND option Page 6 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) selection. ----PPPP This option inhibits the conversion of port numbers to port names for network files. Inhibiting the conversion may make _l_s_o_f run a little faster. It is also useful when host name lookup is not working properly. ----rrrr [_t] This option puts _l_s_o_f in repeat mode. There _l_s_o_f displays output on open files as selected by other options, delays _t seconds (the default is fifteen), then repeats its output display, delaying and producing output repetitively until stopped with an interrupt or quit signal. When no delay time, _t, is specified, _l_s_o_f uses a default of fifteen. _L_s_o_f marks the end of each set of output: if field output is in progress (the ----FFFF, option has been specified), the marker is `m'; otherwise the marker is ``========''. The marker is followed by a NL character. Repeat mode reduces _l_s_o_f startup overhead, so it is more efficient to use this mode than to call _l_s_o_f repetitively from a shell script, for example. To use repeat mode most efficiently, accompany ----rrrr with specification of other _l_s_o_f selection options, so the amount of kernel memory access _l_s_o_f does will be kept to a minimum. Options that filter at the process level - e.g., ----cccc, ----gggg, ----pppp, ----uuuu - are the most efficient selectors. Repeat mode is useful when coupled with field output (see the ----FFFF, option description) and a supervising _a_w_k or _p_e_r_l script. ----ssss This option directs _l_s_o_f to display file size at all times. It causes the SIZE/OFF output column title to be changed to SIZE. If the file does not have a size, nothing is displayed. The ----oooo and ----ssss options are mutually exclusive; they can't both be specified. When neither is specified, _l_s_o_f displays whatever value - size or offset - is appropriate for the type of file. ----SSSS [_t] This option specifies an optional time-out seconds value for kernel functions - _l_s_t_a_t(2), _r_e_a_d_l_i_n_k(2), and _s_t_a_t(2) - that might otherwise deadlock. The minimum for _t is two; the default, fifteen; when no value is specified, the default is used. Page 7 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) See the BBBBLLLLOOOOCCCCKKKKSSSS AAAANNNNDDDD TTTTIIIIMMMMEEEEOOOOUUUUTTTTSSSS section for more information. ----tttt This option specifies that _l_s_o_f should produce terse output with process identifiers only and no header - e.g., so that the output may be piped to _k_i_l_l(1). This option selects the ----wwww option. ----uuuu _s This option selects the listing of files for the user whose login names or user ID numbers are in the comma-separated set _s - e.g., ``abe'', or ``548,root''. (There should be no spaces in the set.) Multiple login names or user ID numbers are joined in a single ORed set before participating in AND option selection. ----UUUU This option selects the listing of Unix domain socket files. ----wwww This option causes _l_s_o_f to suppress all warning messages. The ----tttt option selects this option. ----XXXX This is a dialect-specific option. AIX: WWWWAAAARRRRNNNNIIIINNNNGGGG:::: use of this option on a busy AIX system might cause an application process to hang so completely that it can neither be killed nor stopped. I have never seen this happen or had a report of it, but I think the possibility exists. This option directs _l_s_o_f to use the kernel readx() function. By default use of readx() is disabled. When AIX readx() use is disabled, _l_s_o_f may not be able to report information for all text and loader file references, but it may also avoid exacerbating an AIX 3.2.x and 4.1[.x] kernel directory search kernel error, known as the Stale Segment ID bug. When readx() is enabled, _l_s_o_f will attempt to report information on the text file being executed by each process and the shared libraries it uses. The readx() function, used by _l_s_o_f or any other Page 8 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) program, to access some sections of kernel virtual memory, can trigger the Stale Segment ID bug. It can cause the kernel's dir_search() function erroneously to believe that part of an in-memory copy of a file system directory has been zeroed. Another application process, distinct from _l_s_o_f, asking the kernel to search the directory - e.g., by using _o_p_e_n(2) - can cause dir_search() to loop forever, thus hanging the application process. Consult the 00FAQ and 00README files of the _l_s_o_f distribution for a more complete description of the Stale Segment ID bug, its APAR, and methods for defining readx() use when compiling _l_s_o_f. -------- The double minus sign option is a marker that signals the end of the keyed options. It may be used, for example, when the first file name begins with a minus sign. It may also be used when the absence of a value for the last keyed option must be signified by the presence of a minus sign in the following option and before the start of the file names. _n_a_m_e_s These are path names of specific files to list. Symbolic links are resolved before use. The first name may be separated from the preceding options with the ``--'' option. If a _n_a_m_e is the mount point of a file system or the device of the mount point of a file system, _l_s_o_f will list all the files open on the file system. If a _n_a_m_e is the base name of a family of multiplexed files - e. g, AIX's /_d_e_v/_p_t_s - _l_s_o_f will list all the associated multipled files on the device that are open - e.g., /_d_e_v/_p_t_s/_1, /_d_e_v/_p_t_s/_2, etc. If a _n_a_m_e is a Unix domain socket name, _l_s_o_f will search for it by the characters of the name alone - both as specified and as resolved from symbolic links. When the socket uses a name that is a symbolic link to another, you must specify the name the socket uses. However, if the socket uses the symbolic link's resolution, you may specify it or the symbolic link origination. When asking _l_s_o_f to search for a Unix domain socket name, be careful to specify its absolute path, just as it appears in kernel structures. Specifying a relative path - e.g. ./_f_i_l_e - in place of the file's absolute path Page 9 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) - e.g., /_t_m_p/_f_i_l_e - won't work because _l_s_o_f must match the characters you specify with what it finds in the kernel structures associated with Unix domain sockets. If a _n_a_m_e is none of the above, _l_s_o_f will list any open files whose device and inode match that of the specified path _n_a_m_e. If you have also specified the ----bbbb option, the only _n_a_m_e_s you may safely specify are file systems for which your mount table supplies alternate device numbers. See the AAAAVVVVOOOOIIIIDDDDIIIINNNNGGGG KKKKEEEERRRRNNNNEEEELLLL BBBBLLLLOOOOCCCCKKKKSSSS and AAAALLLLTTTTEEEERRRRNNNNAAAATTTTEEEE DDDDEEEEVVVVIIIICCCCEEEE NNNNUUUUMMMMBBBBEEEERRRRSSSS sections for more information. Multiple file names are joined in a single ORed set before participating in AND option selection. SSSSEEEECCCCUUUURRRRIIIITTTTYYYY At the local administrator's discretion, _l_s_o_f may be constructed with its security option enabled or disabled. When the security option is enabled, _l_s_o_f will allow only the root user to list all open files. The non-root user may list only open files of processes with the same user IDentification number as the real user ID number of the _l_s_o_f process (the one that its user logged on with). When the security option is disabled, anyone may list all open files. The last line of the help output, presented in response to the ----???? or ----hhhh option, gives the security mode status. If the _l_s_o_f user declares alternate kernel name list or memory files with the ----cccc and ----kkkk options, _l_s_o_f will check the user's authority to read them with _a_c_c_e_s_s(2). This prevents whatever special power _l_s_o_f'_s modes might confer on it from letting it read files not normally accessible via the authority of the real user ID. OOOOUUUUTTTTPPPPUUUUTTTT This section describes the information _l_s_o_f lists for each open file. See the OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRR OOOOTTTTHHHHEEEERRRR PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS section for additional information on output that can be processed by another program. COMMAND contains the first nine characters of the name of the Unix command associated with the process. PID is the Process IDentification number of the process. PGRP is the process group IDentification number Page 10 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) associated with the process. It is only displayed when the ----gggg option has been specified. USER is the user ID number or login name of the user to whom the process belongs. (See the ----llll option.) FD is the File Descriptor number of the file or: ccccwwwwdddd current working directory; LLLL_n_n library references; llllttttxxxx shared library text (code and data); MMMMxxxxxxxx hex memory-mapped type number xx. mmmm88886666 DOS Merge mapped file; mmmmeeeemmmm memory-mapped file; ppppdddd parent directory; rrrrttttdddd root directory; ttttxxxxtttt program text (code and data); vvvv88886666 VP/ix mapped file; FD is followed by one of these characters, describing the mode under which the file is open: rrrr for read access; wwww for write access; uuuu for read and write access; space if unknown (e.g., ccccwwwwdddd or ttttxxxxtttt). The mode character is followed by one of these characters, describing the type of lock applied to the file: rrrr for read lock on part of the file; RRRR for a read lock on the entire file; wwww for a write lock on part of the file; WWWW for a write lock on the entire file; space if there is no lock. TYPE is the type of the node associated with the file - e.g., GDIR, GREG, VDIR, VREG, etc. or ``dnet'' for a DECnet socket; or ``inet'' for an Internet domain socket; or ``lla'' for a HP-UX link level access file; or ``rte'' for an AF_ROUTE socket; or ``sock'' for a socket of unknown domain; Page 11 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) or ``unix'' for a Unix domain socket; or ``x.25'' for an HP-UX x.25 socket; or ``BLK'' for a block special file; or ``CHR'' for a character special file; or ``DIR'' for a directory; or ``FIFO'' for a FIFO special file; or ``LINK'' for a symbolic link file; or ``MPB'' for a multiplexed block file; or ``MPC'' for a multiplexed character file; or ``PCTL'' for a /proc control file; or ``PCUR'' for the current /proc process; or ``PDIR'' for a /proc directory; or ``PFIL'' for an executable /proc file; or ``PFPR'' for a /proc FP register set; or ``PGRP'' for a /proc group notifier file; or ``PIPE'' for an Ultrix 4.2 pipe; or ``PMEM'' for a /proc memory image file; or ``PNTF'' for a /proc process notifier file; or ``PORT'' for an Ultrix SYSV named pipe; or ``PREG'' for a /proc register file; or ``PSTA'' for a /proc status file; or ``REG'' for a regular file. DEVICE contains the major and minor device numbers for a character special, block special, regular, directory or NFS file (an HP-UX minor device number is listed in hexadecimal, as is a DEC OSF/1 minor device number larger than 99,999); or the protocol control block address of a DECnet (Ultrix 4.[23]), Internet, Unix, or x.25 (HP-UX) Page 12 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) network file - the address that appears in the ----AAAA output from some _n_e_t_s_t_a_t(1) programs; or ``memory'' for a memory file system node under OSF/1 on the DEC Alpha; or the address of the private data area of a Solaris socket stream; or a kernel reference address that identifies the file. The kernel reference address may be used for FIFO's, for example. Usually only the lower thirty two bits of OSF/1 DEC Alpha kernel addresses are displayed. SIZE/OFF or OFFSET is the size of the file or the file offset in bytes. _L_s_o_f displays whatever value - size or offset - is appropriate for the type of the file. The file size is displayed in decimal; the offset is displayed in decimal with a leading ``0t'' if it is less than 100,000,000; in hexadecimal with a leading ``0x'' if it is larger than 99,999,999. Thus the leading ``0t'' and ``0x'' identify an offset when the column may contain both a size and an offset (i.e., its title is SIZE/OFF). If the ----oooo option is specified, _l_s_o_f always displays the file offset (or nothing if no offset is available) and labels the column OFFSET. The offset always begins with ``0t'' or ``0x'' as described above. If the ----ssss option is specified, _l_s_o_f always displays the file size (or nothing if no size is available) and labels the column SIZE. The ----oooo and ----ssss options are mutually exclusive; they can't both be specified. If size is being displayed and the mode of a Unix domain socket is read-only, the receive buffer size is displayed; write-only, the write buffer size; read and write, the sum of the two buffer sizes. If size is being displayed and the mode of a Solaris TCP socket is read-only, the undelivered receive window size is displayed; write-only, the unacknowledged transmit window size; read and write, the sum of the two window sizes. INODE is the inode number of a local file, truncated and prefixed with an asterisk (`*') if it is too Page 13 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) large for the output field; or the inode number of an NFS file in the server host, truncated and prefixed with an asterisk (`*') if the number is too large for the output field; ; or the Internet protocol type - e. g, ``TCP''; or ``STR'' for a stream; or ``CCITT'' for an HP-UX x.25 socket. NAME is the name of the mount point and file system on which the file resides (Under IRIX 5.2 the appearance of ``(PIPE)'' identifies a pipe file.); or the name of a file specified in the _n_a_m_e_s option (after any symbolic links have been resolved); or the name of a character special or block special device; or the local and remote Internet addresses of a network file (as numbers or names, depending on the ----HHHH and ----PPPP options); a UDP destination Internet address may be followed by the amount of time that's elapsed since the last packet was sent to the destination; or the local and remote node and object addresses of a DECnet file (The node address appears as an _a_r_e_a._n_o_d_e number pair if the ----HHHH option is specified.); or the address or name of a Unix domain socket; or the local and remote mount point names of an NFS file; or ``STR'', followed by the stream name; or a stream character device name, followed by ``->'' and the stream name; or ``STR:'' followed by the SCO Unix stream device and module names, separated by ``->''; or the SunOS current working or root directory path name; Page 14 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) system directory name, `` -- '', and as many components of the path name as _l_s_o_f can find in the kernel's name cache for selected dialects (See the KKKKEEEERRRRNNNNEEEELLLL NNNNAAAAMMMMEEEE CCCCAAAACCCCHHHHEEEE section for more information.); or ``PIPE->'', followed by a Solaris kernel pipe destination address; or ``COMMON:'' for an IRIX (versions below 5.2) common file system entry; or ``COMMON:'', followed by the vnode device information structure's device name, for a Solaris common vnode; or the address family, followed by a slash (`/'), followed by fourteen comma-separated bytes of a non-Internet raw socket address; or the HP-UX x.25 local address, followed by the virtual connection number (if any), followed by the remote address (if any); or ``(dead)'' for disassociated OSF/1 DEC Alpha files - typically terminal files that have been flagged with the TIOCNOTTY ioctl and closed by daemons; or ``rrrr=_c_o_u_n_t/_b_y_t_e_s wwww=_c_o_u_n_t/_b_y_t_e_s'' for incomplete EP/IX 2.1.1 file structures (ones with no vnode or socket pointer), with rrrr signifying read statistics, _c_o_u_n_t giving the operation count, _b_y_t_e_s giving bytes transferred, wwww signifying write statistics; or ``rd=<offset>'' and ``wr=<offset>'' for the values of the read and write offsets of a FIFO. OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRR OOOOTTTTHHHHEEEERRRR PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS When the ----FFFF option is specified, _l_s_o_f produces output that is suitable for processing by another program - e.g, an _a_w_k or _p_e_r_l script. Each unit of information is output in a field that is identified with a leading character and terminated by a NL (012) (or a NUL (000) if the 0 (zero) field identifier character is specified.) The data of the field follows immediately after the field identification character and extends to the field terminator. Page 15 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) It is possible to think of field output as process and file sets. A process set begins with a field whose identifier is `p' (for process IDentifier (PID)). It extends to the beginning of the next PID field or the beginning of the first file set of the process, whichever comes first. Included in the process set are fields that identify the command, the process group IDentification (PGRP) number, and the user ID (UID) number or login name. A file set begins with a field whose identifier is `f' (for file descriptor). It is followed by lines that describe the file's access mode, lock state, type, device, size, offset, inode, protocol, name and stream module names. It extends to the beginning of the next file or process set, whichever comes first. When the NUL (000) field terminator has been selected with the 0 (zero) field identifier character, _l_s_o_f ends each process and file set with a NL (012) character. _L_s_o_f always produces one field, the PID (`p') field. All other fields may be declared optionally in the field identifier character list that follows the ----FFFF option. It is entirely possible to select a set of fields that cannot easily be parsed - e.g., if the field descriptor field is not selected, it may be difficult to identify file sets. To help you avoid this difficulty, _l_s_o_f supports the ----FFFF option; it selects the output of all fields with NL terminators (the ----FFFF0000 option pair selects the output of all fields with NUL terminators). These are the fields that _l_s_o_f will produce. The single character listed first is the field identifier. a file access mode c process command name d file's device character code D file's major/minor device number (0x<hexadecimal>) f file descriptor i file's inode number l file's lock status L process login name m marker between repeated output n file name, comment, Internet address o file's offset (0t<decimal> or 0x<hexadecimal>) p process ID (always selected) g process group ID P protocol name s file's size S file's stream identification t file's type Page 16 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) u process user ID 0 use NUL field terminator character in place of NL You can get on-line help information on these characters and their descriptions by specifying the ----FFFF???? option pair. (Escape the `?' character as your shell requires.) Additional information on field content can be found in the OOOOUUUUTTTTPPPPUUUUTTTT section. As an example, ``----FFFF ppppccccffffnnnn'' will select the process ID (`p'), command name (`c'), file descriptor (`f') and file name (`n') fields with an NL field terminator character; ``----FFFF ppppccccffffnnnn0000'' selects the same output with a NUL (000) field terminator character. _L_s_o_f doesn't produce all fields for every process or file set, only those that are available. Some fields are mutually exclusive: file device characters and file major/minor device numbers; file inode number and protocol name; file name and stream identification; file size and offset. One or the other member of these mutually exclusive sets will appear in field output, but not both. Normally _l_s_o_f ends each field with a NL (012) character. The 0 (zero) field identifier character may be specified to change the field terminator character to a NUL (000). A NUL terminator may be easier to process with _x_a_r_g_s (_1), for example, or with programs whose quoting mechanisms may not easily cope with the range of characters in the field output. When the NUL field terminator is in use, _l_s_o_f ends each process and file set with a NL (012). Two aids to producing programs that can process _l_s_o_f field output are included in the _l_s_o_f distribution. The first is a C header file, _l_s_o_f__f_i_e_l_d_s._h, that contains symbols for the field identification characters, indexes for storing them in a table, and explanation strings that may be compiled into programs. _L_s_o_f uses this header file. The second aid is a set of sample scripts that process field output, written in _a_w_k, _p_e_r_l 4, and _p_e_r_l 5. They're located in the _s_c_r_i_p_t_s subdirectory of the _l_s_o_f distribution. BBBBLLLLOOOOCCCCKKKKSSSS AAAANNNNDDDD TTTTIIIIMMMMEEEEOOOOUUUUTTTTSSSS _L_s_o_f can be blocked by some kernel functions that it uses - _l_s_t_a_t(2), _r_e_a_d_l_i_n_k(2), and _s_t_a_t(2). These functions are stalled in the kernel, for example, when the hosts where mounted NFS file systems reside become inaccessible. _L_s_o_f attempts to break these blocks with timers and child processes, but the techniques are not wholly reliable. When _l_s_o_f does manage to break a block, it will report the break Page 17 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) with an error message. The messages may be suppressed with the ----tttt and ----wwww options. The default timeout value may be displayed with the ----???? or ----hhhh option, and it may be changed with the ----SSSS [_t] option. The minimum for _t is two seconds, but you should avoid small values, since slow system responsiveness can cause short timeouts to expire unexpectedly and perhaps stop _l_s_o_f before it can produce any output. When _l_s_o_f has to break a block during its access of mounted file system information, it normally continues, although with less information available to display about open files. AAAAVVVVOOOOIIIIDDDDIIIINNNNGGGG KKKKEEEERRRRNNNNEEEELLLL BBBBLLLLOOOOCCCCKKKKSSSS You can use the ----bbbb option to tell _l_s_o_f to avoid using kernel functions that would block. Some cautions apply. First, using this option usually requires that your system supply alternate device numbers in place of the device numbers that _l_s_o_f would normally obtain with the _l_s_t_a_t(2) and _s_t_a_t(2) kernel functions. See the AAAALLLLTTTTEEEERRRRNNNNAAAATTTTEEEE DDDDEEEEVVVVIIIICCCCEEEE NNNNUUUUMMMMBBBBEEEERRRRSSSS section for more information on alternate device numbers. Second, you can't specify _n_a_m_e_s for _l_s_o_f to locate unless they're file system names. This is because _l_s_o_f needs to know the device and inode numbers of files listed with _n_a_m_e_s in the _l_s_o_f options, and the ----bbbb option prevents _l_s_o_f from obtaining them. Moreover, since _l_s_o_f only has device numbers for the file systems that have alternates, its ability to locate files on file systems depends completely on the availability and accuracy of the alternates. If no alternates are available, or if they're incorrect, _l_s_o_f won't be able to locate files on the named file systems. Third, if the names of your file system directories that _l_s_o_f obtains from your system's mount table are symbolic links, _l_s_o_f won't be able to resolve the links. This is because the ----bbbb option causes _l_s_o_f to avoid the kernel _r_e_a_d_l_i_n_k(2) function it uses to resolve symbolic links. Finally, using the ----bbbb option causes _l_s_o_f to issue warning messages when it needs to use the kernel functions that the ----bbbb option directs it to avoid. You can suppress these messages by specifying the ----wwww option, but if you do, you won't see the alternate device numbers reported in the warning messages. AAAALLLLTTTTEEEERRRRNNNNAAAATTTTEEEE DDDDEEEEVVVVIIIICCCCEEEE NNNNUUUUMMMMBBBBEEEERRRRSSSS On some dialects, when _l_s_o_f has to break a block because it can't get information about a mounted file system via the Page 18 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) _l_s_t_a_t(2) and _s_t_a_t(2) kernel functions, or because you specified the ----bbbb option, _l_s_o_f can obtain some of the information it needs - the device number and possibly the file system type - from the system mount table. When that is possible, _l_s_o_f will report the device number it obtained. (You can suppress the report by specifying the ----wwww option.) You can assist this process if your mount table is supported with an /_e_t_c/_m_t_a_b or /_e_t_c/_m_n_t_t_a_b file that contains an options field by adding a ``dev=xxxx'' field for mount points that do not have one in their options strings. The ``xxxx'' portion of the field is the hexadecimal value of the file system's device number. (Consult the _s_t__d_e_v field of the output of the _l_s_t_a_t(2) and _s_t_a_t(2) functions for the appropriate values for your file systems.) Here's an example from an SGI IRIX 5.2 /_e_t_c/_m_t_a_b for a file system remotely mounted via NFS: ... nfs rw,grpid,intr,nodevs,retry=6,dev=00100007 ... There's an advantage to having ``dev=xxxx'' entries in your mount table file, especially for file systems that are mounted from remote NFS servers. When a remote server crashes and you want to identify its users by running _l_s_o_f on one of its clients, _l_s_o_f probably won't be able to get output from the _l_s_t_a_t(2) and _s_t_a_t(2) functions for the file system. If it can obtain the file system's device number from the mount table, it will be able to display the files open on the crashed NFS server. Some dialects that do not use an ASCII /_e_t_c/_m_t_a_b or /_e_t_c/_m_n_t_t_a_b file for the mount table may still provide an alternative device number in their internal mount tables. This includes AIX, DEC OSF/1, FreeBSD, NetBSD, and Ultrix. _L_s_o_f knows how to obtain the alternative device number for these dialects and uses it when its attempt to _l_s_t_a_t(2) or _s_t_a_t(2) the file system is blocked. If you're not sure your dialect supplies alternate device numbers for file systems from its mount table, use this _l_s_o_f incantation to see if it reports any alternate device numbers: lsof -b Look for standard error file warning messages that begin ``assuming "dev=xxxx" from ...''. KKKKEEEERRRRNNNNEEEELLLL NNNNAAAAMMMMEEEE CCCCAAAACCCCHHHHEEEE _L_s_o_f is able to examine the kernel's name cache on some dialects and extract recently used path name components from Page 19 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) it. _L_s_o_f reports the ones it finds in the NAME column, starting with the file system name, followed by a space, two `-' characters, another space, and the name components it has located, separated by the `/' character. _L_s_o_f can report path name components for these dialects: DYNIX 3.0.12 (Purdue version) EP/IX 2.1.1 FreeBSD 1.1.5.1, 2.0, and 2.0.5 HP-UX 9.x and 10 Motorola V/88 R40V4.2 NetBSD 1.0 and 1.0A NEXTSTEP 3.[0123] OSF/1 2.0, 3.0, and 3.2 PTX 2.1.[156] and 4.0.[23] SGI IRIX 5.3 Solaris 2.[34] SunOS 4.1.[23] Ultrix 2.2, 4.2, and 4.3 _L_s_o_f can't report path name components for these dialects: AIX 3.2.4, 3.2.5, 4.1, 4.1.1, and 4.1.2 DC/OSx 1.1 Linux Motorola V/88 R32V3 Novell UnixWare 1.1, 1.1.1, and 1.1.2 SCO OpenDesktop or OpenServer 1.1 and 3.0 SGI IRIX 4.0.5H, 5.2, and 6.0 _L_s_o_f may be able to report path name components for these dialects, but the code hasn't been tested on them: HP-UX 8.x NEXTSTEP 2.1 OSF/1 1.3 Solaris 2.[12] SunOS 4.1.[14] Ultrix 4.3 and 4.4 If you want to know why _l_s_o_f can't report path name components for some dialects, consult section 3.1 of the _0_0_F_A_Q file of the _l_s_o_f distribution. DDDDEEEEVVVVIIIICCCCEEEE CCCCAAAACCCCHHHHEEEE FFFFIIIILLLLEEEE Examining all members of the /_d_e_v node tree with _s_t_a_t(2) functions can be time consuming. What's more, the information that _l_s_o_f needs - device number, inode number, and path - rarely changes. Consequently, at revision 3.19 _l_s_o_f has begun maintaining an Page 20 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) ASCII text file of cached /_d_e_v information. The standard path for the device cache file is /_t_m_p/._l_s_o_f__d_e_v__c_a_c_h_e, but the local system administrator may change the path when _l_s_o_f is compiled, or the default path for some systems my be slightly shorter. (Consult the output of the ----???? or ----hhhh option for the current default path.) The ----DDDD option provides some control over the cache. It allows you to request that the cache file be built in a specific location (bbbb[_p_a_t_h]); ignored (iiii); read but not rebuilt (rrrr[_p_a_t_h]); or read and rebuilt (uuuu[_p_a_t_h]). The uuuu function is the default when no ----DDDD option has been specified, using the default device cache file path /_t_m_p/._l_s_o_f__d_e_v__c_a_c_h_e. This function tells _l_s_o_f to attempt to read and use the device cache file. If it can't read the file, it will read information from the kernel with _s_t_a_t(2) function calls, then write an updated version of the file. The device cache file is stored by default in /tmp with read and write permission for owner, group, and user, so any _l_s_o_f call can access or rebuild it. (You can change the device cache file path with the optional _p_a_t_h suffix of the bbbb, rrrr, and uuuu functions.) _L_s_o_f can detect that the file has been accidentally or maliciously modified by several sanity checks, including a sixteen bit Cyclic Redundancy Check (CRC) sum of the file's contents. When _l_s_o_f senses something wrong with the file, it will attempt to remove the current one and create a new copy. On those rare occasions when a new device is added to the system, the device cache file may need to be recreated. Since _l_s_o_f compares the mtime of the device cache file with the mtime and ctime of the device directory (usually /dev) it often can detect that a new device has been added; in that case _l_s_o_f issues a warning message and rebuilds the device cache file, depending on the function specified in the ----DDDD option. If _l_s_o_f doesn't update the cache file when you believe it should, use the bbbb function of ----DDDD to make it recreate the file. DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS Errors are identified with messages on the standard error file. _L_s_o_f returns a one (1) if any error was detected, including the failure to locate any _n_a_m_e_s. It returns a zero (0) if no errors were detected and if it was able to list Page 21 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) information about all the specified _n_a_m_e_s. When _l_s_o_f cannot open access to /_d_e_v (or /_d_e_v_i_c_e) or one of its subdirectories, it issues a warning message and continues. The warning message may be suppressed with the ----wwww option. It may also have been suppressed by the system administrator when _l_s_o_f was compiled by the setting of the WARNDEVACCESS definition. In the latter case, the output from _l_s_o_f'_s ----???? or ----hhhh option will contain the message: Warnings are disabled for inaccessible device directories. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS To list all open files, use: lsof To list all open Internet, x.25 (HP-UX), and Unix domain files, use: lsof -n -U To list all files using any protocol on port 513 of host wonderland.cc.purdue.edu, use: lsof -i @wonderland.cc.purdue.edu:513 To list all files using any protocol on any port of mace.cc.purdue.edu (cc.purdue.edu is the default domain), use: lsof -i @mace To list all open files for login name ``abe'', or user ID 1234, or process 456, or process 123, or process 789, use: lsof -p 456,123,789 -u 1234,abe To list all open files on device /dev/hd4, use: lsof /dev/hd4 To find the process that has /u/abe/foo open, use: lsof /u/abe/foo To send a SIGHUP to the processes that have /u/abe/bar open, use: kill -HUP `lsof -t /u/abe/bar` To find any open file, including an open Unix domain socket Page 22 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) file, with the name /_d_e_v/_l_o_g, use: lsof /dev/log To find processes with open files on the NFS file system named /_n_f_s/_m_o_u_n_t/_p_o_i_n_t whose server is inaccessible, and presuming your mount table supplies the device number for /_n_f_s/_m_o_u_n_t/_p_o_i_n_t, use: lsof -b /nfs/mount/point To do the preceding search with warning messages suppressed, use: lsof -bw /nfs/mount/point To ignore the device cache file, use: lsof -Di To read the device cache file named Xyz in the current directory and update it, if necessary, use: lsof -DuXyz To obtain PID and command name field output for each process, file descriptor, file device number, and file inode number for each file of each process, use: lsof -FpcfDi To list the files at descriptors 1 and 3 of every process running the _l_s_o_f command for login ID ``abe'' every 10 seconds, use: lsof -c lsof -a -d 1 -d 3 -u abe -r10 BBBBUUUUGGGGSSSS Since _l_s_o_f reads kernel memory in its search for open files, rapid changes in kernel memory may produce unpredictable results. The lock status character (following the file descriptor) is derived under AIX from a test of the first filock structure of the gnode (see <sys/flock.h> and <sys/gnode.h>). _L_s_o_f can't search for files with restrictive access permissions by _n_a_m_e unless it is installed with root set-UID permission. Otherwise it is limited to searching for files to which its user or its set-GID group (if any) has access permission. Page 23 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) _L_s_o_f startup time is long on dialects where scanning the /_d_e_v (or /_d_e_v_i_c_e_s) directory and the mount table are slow operations. Where possible - e.g., when the listing of only network files is requested - the scans are avoided or deferred. When the device cache file is in use, scanning /_d_e_v is avoided once the cache file has been written. The display of the destination address of a raw socket (e.g., for _p_i_n_g) depends on the Unix operating system. Some dialects store the destination address in the raw socket's protocol control block, some do not. _L_s_o_f can't always represent Solaris and SunOS device numbers in the same way that _l_s(1) does. For example, the major and minor device numbers that the _l_s_t_a_t(2) and _s_t_a_t(2) functions report for the directory on which CD-ROM files are mounted (typically /_c_d_r_o_m) are not the same as the ones that it reports for the device on which CD-ROM files are mounted (typically /_d_e_v/_s_r_0). (_L_s_o_f reports the directory numbers.) The system to which the Ultrix 2.2 port was directed is a local one that has been extensively updated with network features from the 4.3BSD Tahoe and Reno releases, so it may not match a standard Ultrix 2.2 system, if there is any such system still in use. The support for /proc file systems is available only for BSD and OSF dialects, Linux, and dialects derived from SYSV R4 - e.g., FreeBSD, IRIX 5.[23], NetBSD, Solaris, V/88 R40V4.[23], UnixWare. One SYSV R4 exception is EP/IX 2.1.1, where I have been unable to overcome conflicts between its svr3 and svr4 environments to build an _l_s_o_f with /proc file system support. Some /proc file items - device number, inode number, and file size - are unavailable in some dialects. No text (ttttxxxxtttt) file descriptors are displayed for Linux processes. All entries for files other than the current working directory, the root directory, and numerical file descriptors are labeled mmmmeeeemmmm descriptors. FFFFIIIILLLLEEEESSSS /_d_e_v/_k_m_e_m kernel virtual memory device /_d_e_v/_m_e_m physical memory device /_d_e_v/_s_w_a_p system paging device /_t_m_p/._l_s_o_f__d_e_v__c_a_c_h_e _l_s_o_f'_s device cache file AAAAUUUUTTTTHHHHOOOORRRRSSSS _L_s_o_f was written by Victor A. Abell <abe@cc.purdue.edu> of Page 24 (printed 7/31/95) LLLLSSSSOOOOFFFF((((8888)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeevvvviiiissssiiiioooonnnn----3333....33337777)))) LLLLSSSSOOOOFFFF((((8888)))) the Purdue University Computing Center (PUCC), starting from the _f_s_t_a_t and _o_f_i_l_e_s programs. Anthony Shortland <Anthony.Shortland@FMR.com> produced the Pyramid DC/OSx 1.1 support. Vic acknowledges his debt to the work of Dan Bernstein, Michael ``Ford'' Ditto, Tom Dunigan, Alexander Dupuy, Vik Lall, Ray Moody, C. Spencer, Michael Spitzer and those who wrote Berkeley's _f_s_t_a_t program, all contributors to _l_s_o_f'_s predecessors. Vic thanks Doug McKenzie for his HP-UX _p_r_o_c_t_o_r program and Rich Kulawiec for pointing it out. Finally, Vic is grateful to David Addison, Richard Allen, Marc Auslander, Ade Barkah, Anthony Baxter, John Beacom, Bruce Beare, Dave Bianchi, Achim Bohnet, Mark Bonsack, Bill Bormann, Michael Bryan, Bernt Christandl, Hans Petter Christiansen, Axel Clauberg, John Colgrave, Jim Cooper, Dave Curry, Ian Darwin, Hugh Dickins, Casper Dik, Greg Earle, Robert Ehrlich, Doug Eldred, Scott Ellentuch, Tom Endo, Mike Feldman, Bob Foertsch, Mike Fraser, Terry Friedrichsen, David DiGiacomo, Garner Halloran, Adam Hammer, Charles Hannum, Steinar Haug, Paul Hite, J. Nelson Howell, Gerrit Huizenga, John Jackson, Kurt Jaeger, Carl Johnson, Dion Johnson, Peter Jordan, Pasi Kaara, Frank Kaefer, Claus Kalle, Shane Kenney, Steve Kirsch, Przemek Klosowski, Paul Kranenburg, Alex Kreis, Markus Lautenbacher, Steve Lacey, Marty Leisner, Stuart Levy, Wendy Lin, Friedel Loinger, Michael Long, Pete Lord, Bela Lubkin, Horst Luehrsen, Andreas Luik, Michael Mackenzie, Lawrence MacIntyre, Benson Margulies, Claude Marinier, Fletcher Mattox, Dale McCluskey, Sean McDermott, Dwight McKay, William McVey, Jeffrey Mogul, Dave Morrison, Pat Myrto, Allan Nathanson, Chance Neale, Joseph J. Nuspl Jr., Craig B. Olofson, Dave Olson, Mark Peek, Ezra Peisach, Nathan Peterson, Dominique Petitpierre, Francois Pinard, Alex Podlecki, Philippe-Andre Prindeville, David Putz, Tim Ramsey, Stephan Rossi, Kevin Ruderman, Chris Schanzle, Hendrik G. Seliger, Michael Shields, Anthony Shortland, John Silva, Gerry Singleton, Leonard Sitongia, Kevin Smallwood, Douglas R. Smith, Dave Stevens, Jeff Stewart, Andreas Stolcke, Dale Talcott, Andy Thomas, Chris Timmons, Zdenko Tomasic, Linus Torvalds, Lenny Turetsky, Jules van Weerden, Robert Vernon, Jos Vos, Joel White, Patrick Wolfe, James Woodward, and Ron Young for their help in developing and improving _l_s_o_f. SSSSEEEEEEEE AAAALLLLSSSSOOOO access(2), awk(1), ff(1), fstat(8), fuser(1), kill(1), lstat(2), netstat(1), ofiles(8L), perl(1), ps(1), readlink(2), stat(2). Page 25 (printed 7/31/95)